... 所要求的義務－隨產品有完整的著作權聲明及標示，則被告的行為不僅違反契約也構成著作權侵權。地方法院必須依據上訴法院就本案所認定之法律關係重新做出是否准許核發禁制令給原告 Jacobsen 之決議（註二）。 這個案子從一開始就受到自由／開放原碼社群的注意，因為原告 Jacobsen 所管理的 JMRI 計劃是一個自由／開放原碼軟體，主要在發展模型火車的控制軟體，而該軟體運用系統稱為 DecorderPro。且原告允許模型火車的愛好者可自由從 ...

...  為了避免這些問題情況的發生，筆者提出的建議是：無論對於原軟體小修或大改，修改後的軟體均採用第 (2) 標示著作權聲明，同時加上簡短說明文字，說明是從哪一個軟體修改而來的，以及原軟體的著作權人或開發者為何。套用在本文所提到的例子，B 的著作權聲明可以是這樣： 2006 (C) Software B, Copyright Owner B' Software B is derived from ...

自己寫了一個程式，想要用自由軟體的方式來授權這個程式，卻不知道該如何做？這是不少人的疑惑。其實，就目前大部分的自由軟體授權條款的規定來看，並沒有一定必須遵守的宣告方式，所以重點就在於：要讓他人可以清楚明確地知道這個程式是採用自由軟體方式來授權。   一、條款全文 將授權條款附在程式中一起散布，這是最簡單的方法。像採用 BSD、MIT 這一類簡短條款授權的話，就可以將條款全文附在每一個原始碼檔案的一開始，這樣利用其中任意一個原始碼檔案的人，也可以明確地知道這些原始碼是採用 ...

一般人對於自由開源授權條款的運用，都是原封不動地將條款套用到程式上，不過也有些情況是專案開發者對於程式運用方式有特定想法，此時不見得所有授權條款均可以符合開發者的特定想法，因此就會有修改授權條款的需要。 一份授權條款是否容許他人自行修改後使用，就要看當初草擬條款的著作權人是否授權修改，而是否授權修改可以從看條款本身的規定或者是其著作權聲明中得之。 有些條款在授權文字中即有規定使用者可以修改條款內容，但是修改過條款必須使用與原條款不同的名稱，避免他人與原條款混淆，例如 ...